We now compare nested generics wrapped into TypeInformation to consider type equality for deeply parametrized types.
Previously, we resolved type parameters to Class so Foo<List<String>> was considered equal to Foo<List<Map>> as the type parameter of the first nesting level was erased.
Closes#3051
The Lock utility is an adapter for Java's Lock and ReadWrite Lock types providing an easier to consume programming model (callback-style and try-with-resources).
Closes: #2944
Guard usage of KotlinReflectUtils with type presence check.
Extend tests to cover primitive arrays.
Move methods from KotlinValueUtils to KotlinReflectUtils.
Move copy value cache to KotlinCopyMethod.
Original Pull Request: #2866
This commit introduces support for Kotlin Value Classes which are designed for a more expressive domain model to make underlying concepts explicit. Spring Data can now read and write types that define properties using Value Classes.
The support covers reflection based instantiation of Kotlin inline class, nullability and defaulting permutations as well as value classes with generics.
Closes: #1947
Original Pull Request: #2866
Java8 bytecode may contain synthetic constructors that refer to anonymous classes which should not be inspected.
Eg. the following construct results in bytecode as listed further down below.
public enum Outer {
INSTANCE {
@Override
public Inner getInnerType() {
return Inner.STANDALONE;
}
},
public abstract Inner getInnerType();
}
synthetic Outer(java.lang.String arg0, int arg1, Inner$1 arg2)
See: #2744
Original pull request: #2746
Also update the type filter that would not mach types directly present in the given package.
Modify type contribution method to allow store specific override.
Closes: #2744
Original pull request: #2746
Added dedicated Lazy.toString() rendering the resolved value's ….toString() method but resorts to a constant [Unresolved] if it's not already resolved. An additional ….toString(Supplier<String>) allows to customize the fallback message if needed.
Fixes#2751.
This commit introduced support for registering GraalVM native reflection type hints for Querydsl Q types that target domain types used in the repository interface declaration.
At this point we only do a simple lookup for Q types based in the very same package that implement EntityPath.
More advanced configuration (eg. base package and type prefix), potentially available via EntityPathResolver are not taken into account as this would require eager bean resolution from the application context, which is likely to trigger additional infrastructure. In this case the user is required to register Q types manually.
Closes: #2721
Original pull request: #2743.
ReactiveWrappers is not tied to repositories so it does not need to reside in the repository.util package. This utility is now located in the data.util package for a better module design and to prevent package cycles.
See #2708
Slight refinements in TypeDiscoverer.equals(…) / hashCode() that are still not completely valid, are different enough to work for differentiating use cases but not 100% efficient for cache cases. Captured outstanding work in spring-projects/spring-data-commons#2643.
Reimplemented ….repository.query.Parameter.isDynamicProjectParameter(…) to bild on TypeInformation completely and properly unwrapp *all* wrapper types for type comparison.
Related ticket #2312.
Reworked the implementation of the TypeInformation type hierarchy to be based on Spring's ResolvableType for most of the heavy-lifting.
Original pull request: #2572.
Related ticket: #2312.
We now return a default value for invocations of methods returning a primitive value to pass the AOP infrastructure's check for compatible values. Before, that barked at the null value returned for the invocation.
Fixes#2612.
Removed the removal of the general collection-to-object converter as apparently some downstream Spring Data modules rely on it. This theoretically allows conversions of collections into maps but we now simply don't assume that not to work anymore.
Issue #2619.
Custom collection support is now centralized in ….util.CustomCollections. It exposes API to detect whether a type is a map or collection, identifies the map base type etc.
Support for different collection implementations is externalized via the CustomCollectionRegistrar SPI that allows to define implementations via spring.factories. The current support for Vavr collections has been moved into an implementation of that, VavrCollections.
Unit tests for custom collection handling and conversion previously living in QueryExecutionConverterUnitTests have been moved into CustomCollectionsUnitTests.
Fixes#2619.
Avoid leaking internals from TypeInformation by exposing a ….toTypeDescriptor() method in TypeInformation directly. This causes the ResolvableType handling to become an implementation detail within ClassTypeInformation and avoid client code to manually deal with both ResolvableType and TypeDescriptor creation.
Changed MethodLookups back to use the resolved domain types as the advanced generics resolutions seems not to be needed here and we can avoid
Fixes#2518.
Moved Vavr collection converters into a type in the utility package. Register the converters via CustomConversions.registerConvertersIn(…) to make sure that all the Spring Data object mapping converters automatically benefit from a ConversionService that is capable of translating between Java-native collections and Vavr ones.
Issue #2511.
Use var instead of explicit local types where applicable. Use pattern variable instead instanceof and cast. Prefer loops and nullable types over Stream and Optional. Convert classes to records where applicable.
See #2465
