This commits extends nullability declarations to the field level, formalizing the interaction between methods and their underlying fields and therefore avoiding any nullability mismatch.
Issue: SPR-15720
This commit also removes nullability from two common spots: ResolvableType.getType() and TargetSource.getTarget(), both of which are never effectively null with any regular implementation. For such scenarios, a non-null empty type/target is the cleaner contract.
Issue: SPR-15540
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
The change to "optimize" the template by not rebuilding the reply
message when the original header channels was null was incorrect.
We need to null out those headers if they were originally null.
Issue: SPR-15991
Provide a mechanism to override the configured send and receive
timeouts in the GenericMessagingTemplate.
- overload `doReceive()` to take a receive timeout argument
- for `sendAndReceive()` methods examine message headers for these
timeout values
- remove headers to avoid propagation
- avoid the unconditional rebuild of the reply message if the
original headers weren't present
- also remove headers from simple `send()` operations
- change javadocs for the setters to indicate they are now defaults
- add properties to allow the user to override the header names used
- change `TemporaryReplyChannel` to use `send` arg and change to static
- add package-protected ctor to avoid the compiler creating a
synthetic constructor for access
Issue: SPR-15591
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
Currently the BOM versions are:
* reactor-core 3.0.6.BUILD-SNAPSHOT
* reactor-netty 0.6.2.BUILD-SNAPSHOT
This commit fixes as well a few deprecations in reactor-core.
This commit *adds* the "intercepted" headers to the ClientHttpRequest,
as opposed to replacing them, which is what happened before this commit.
Issue: SPR-15166
Juergen Hoeller
Alan Hong
Violeta Georgieva
Stephane Nicoll
diguage
Arjen Poutsma
Rob Winch
Rossen Stoyanchev
Christoph Dreis
Sebastien Deleuze
Gary Russell
Bao Tran
Alexander Riss
Brian Clozel
stonio
Stephane Maldini