Create internal variants of the existing `AnnotationUtils` and
`AnnotatedElementUtils` classes and migrate the existing classes to
use them.
The internal variants will be used to check that the same results are
given as we migrate the utils methods to use the new `MergedAnnotations`
API.
See gh-22562
Add new `MergedAnnotations` and `MergedAnnotation` interfaces that
attempt to provide a uniform way for dealing with merged annotations.
Specifically, the new API provides alternatives for the static methods
in `AnnotationUtils` and `AnnotatedElementUtils` and supports Spring's
comprehensive annotation attribute `@AliasFor` features. The interfaces
also open the possibility of the same API being exposed from the
`AnnotationMetadata` interface.
Additional utility classes for collecting, filtering and selecting
annotations have also been added.
Typical usage for the new API would be something like:
MergedAnnotations.from(Example.class)
.stream(MyAnnotation.class)
.map(a -> a.getString("value"))
.forEach(System.out::println);
Closes gh-21697
Add a new test class to help cover annotation introspection failure
handling. These tests were previously missing and are important to
ensure that annotation util code changes don't introduce regressions.
See gh-21697
Add a public variant of `getDeclaredMethods` that defensively copies the
cached methods array. This is often more faster and more convenient
for users than calling `doWithLocalMethods`. We still retain most of the
benefits of the cache, namely fewer security manager calls and not as
many `Method` instances being created.
Closes gh-22580
Prior to this commit, the exception message generated by
instantiateFactory() in SpringFactoriesLoader did not report the
offending class in the top-level exception message. The offending class
was in fact included in the message of the nested exception, but the
top-level exception message on its own was a bit misleading.
This commit improves the diagnostics for such failures by including the
offending class and the target factory type in the top-level exception
message.
Closes gh-22453
Before this commit, the return type for Kotlin suspending functions
(as returned by MethodParameter#getParameterType and
MethodParameter#getGenericReturnType methods) was incorrect.
This change leverages Kotlin reflection instead of Java one
to return the correct type.
Closes gh-21058
- Integration tests run with zero copy configuration.
- RSocketBufferLeakTests has been added.
- Updates in MessagingRSocket to ensure proper release
See gh-21987
Prior to this commit, repeated calls to `DataBuffer.write(CharSequence,
Charset)` would not write the given chars to the expected position in
the original buffer.
This commit fixes that by writing to the `outBuffer.position()`, offset
by the current `DataBuffer.writePosition()`.
Fixes gh-22484
Prior to this commit, `DataBuffer.write` would throw an
`IllegalStateException` when called with an empty `String`, since the
`CharsetEncoder` would be flushed on an incorrent state.
This commit skips entirely the encoding phase for empty `String`.
Fixes#22262
Prior to this commit, one could write a `CharSequence` to an existing
`DataBuffer` instance by turning it into a byte array or `ByteBuffer`
first. This had the following disadvantages:
1. Memory allocation was not efficient (not leveraging pooled memory
when available)
2. Dealing with `CharsetEncoder` is not always easy
3. `DataBuffer` implementations, like `NettyDataBuffer` can use
optimized implementations in some cases
This commit adds a new `DataBuffer#write(CharSequence, Charset)` method
for those cases and also an `ensureCapacity` method useful for checking
that the current buffer has enough capacity to write to it..
Issue: SPR-17558
This commit reverts the first optimizations listed in
fa096dc60f, as the default delimiters
do vary, namely by the charset given in the message mime type.
The mimetype charset might not be compatible with ASCII (i.e. anything
but UTF-8 or ISO-8859-1, for instance it might be UTF-16), and will not
successfully find the default delimiters as a consequence.
Added test to indicate the bug.
Fix ResourceRegionEncoder so that it checks for resource existance
before writing boundaries. Also defer data buffer allocation until
necessary.
Issue: SPR-17419
As discussed in KT-25165, from a Kotlin POV enum constructors
have no parameter, this is an "implementation detail"
required for running on the JVM, so it seems relevant to skip
Kotlin reflection in that case and just delegate to Java
reflection.
Issue: SPR-16931
