This commit improves the capacity calculation for the DefaultDataBuffer,
so that the capacity typically doubles instead of improving by the
minimal required amount.
Issue: SPR-15647
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
Update AnnotationUtils to restore support for `null` arguments in
certain methods. Some existing upstream projects were relying on this
behavior.
Issue: SPR-15642
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
Defining nullability of some API like EnvironmentCapable
or ConditionContext causes issues in Spring Boot because
in the context where they are used, it is known for sure
they will return non-null values even if their API can in
other context return null values.
It is better in this case for both Java and Kotlin to
not define at all the nullabity of such API.
In practice, this is achieved by removing the package level
@NonNullApi annotation and adding it only on the
relevant classes.
Issue: SPR-15540
This commit makes Spring @Nullable annotation leveraging
JSR 305 @TypeQualifierNickname + @Nonnull(when= When.MAYBE)
instead of directly using @javax.annotation.Nullable which
seems not designed to be used as a meta-annotation.
It also removes @TypeQualifierDefault since the purpose of
this annotation when applied at method level is to only
change return value nullability, not parameters one.
Issue: SPR-15540
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
Starting with removing a package cycle on the use of
ResponseStatusException in the codec package, this commit generally
refines codec exception handling.
The new [Encoding|Decoding]Exception mirror the existing
HttpMessageNot[Readable|Writable]Exception and are used similarly
especially to differentiate betwen 400 and 500 errors when parsing
server request body content.
The commit also aligns some of the exception handling of JSON and XML
on the WebFlux side with that on the Spring MVC side.
Issue: SPR-15516
Update `SpringFactoriesLoader` to cache property file loads. This helps
reduce the number of garbage objects created as each load uses an 8K
char buffer.
Issue: SPR-15509
This commit introduces a `writableChannel()` method to
`WritableResource`, defaulting to `Channels.newChannel`, but with
overrides for file-based resources.
- Fixed AnnotationUtils.getValue() operation to ensure it re-throws AnnotationConfigurationException instead of swallowing it (as it is done in few other operations in AnnotationUtils)
- Added test
- Removed unnecessary '@SuppressWarnings("unchecked")'
Includes revised Log methods in log level order, with consistent delegation of fatal->error for log level checks in SLF4J and JUL, a JavaUtilDelegate for defensive access to java.logging on JDK 9, support for LogRecord message objects, as well as revised log setup recommendations.
Issue: SPR-15453
Issue: SPR-14512
This commit adds support for reactive library types to be returned
directly from controller methods adapting them either to a
ResponseBodyEmitter (streaming) or DeferredResult (non-streaming).
The reactive libraries supported are the ones that can adapted to a
Reactive Streams Publisher through the ReactiveAdapterRegistry.
Issue: SPR-15365
Follow-up to:
3d68c496f1
StringDecoder can be created in text-only vs "*/*" mode which in turn
allows a more intuitive order of client side decoders, e.g. SSE does
not have to be ahead of StringDecoder.
The commit also explicitly disables String from the supported types in
Jackson2Decoder leaving it to the StringDecoder in "*/*" mode which
comes after. This does not change the current arrangement since the
the StringDecoder ahead having "*/*" picks up JSON content just the
same.
From a broader perspective this change allows any decoder to deal with
String if it wants to after examining the content type be it the SSE
or another, custom decoder. For Jackson there is very little value in
decoding to String which works only if the output contains a single
JSON string but will fail to parse anything else (JSON object/array)
while StringDecoder in "*/*" mode will not fail.
Issue: SPR-15374
CharSequenceEncoder now supports all MIME types, however since encoding
Flux<String> can overlap with other encoders (e.g. SSE) there are now
two ways to create a CharSequenceEncoder -- with support for text/plain
only or with support for any MIME type.
In WebFlux configuration we insert one CharSequenceEncoder for
text/plain (as we have so far) and a second instance with support for
any MIME type at the very end.
Issue: SPR-15374
Support for flushing in EncoderHttpMessageWriter is now driven from a
configurable list of "streaming" media types with the list including
"application/stream+json" by default.
As a result Jackson2ServerHttpMessageWriter is no longer needed.
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 an overloaded DataBufferUtils.read method that operates
on a AsynchronousFileChannel (as opposed to a ReadableByteChannel, which
already existed). This commit also uses said method in the Resource
encoders, if the Resource is a file.
Juergen Hoeller
diguage
Arjen Poutsma
Stephane Nicoll
Phillip Webb
Sebastien Deleuze
Rossen Stoyanchev
Jon Borenstein
Christoph Dreis
Sam Brannen
Oleg Zhurakousky
stonio
Brian Clozel