We now check whether to use the repository configuration as last check to clarify store module responsibility first. This allows to place store-specific checks in RepositoryConfigurationExtensionSupport.useRepositoryConfiguration(…) such as rejecting reactive repositories for a store module that does not support reactive repositories
Previously, we called useRepositoryConfiguration(…) before checking whether the actual repository interface is handled by the store module. This resulted in rejection of reactive repositories by store modules that do not provide reactive support whereas the repository did not belong to the actual store module.
Related ticket: DATACMNS-1174.
We now avoid using a Lambda to provide a default ObjectMapper instance in the code that's reflectively guarded against Jackson not being present. The lambda causes a method to be generated for the class that will require ObjectMapper to be present on reflection inspection of that method. Switching to a method reference to ObjectMapper's constructor resolves that problem as the indirection via the additional, offending method is not needed.
Further reading: https://www.javabullets.com/how-lambdas-and-anonymous-inner-classesaic-work/
One of the constructors of Pageable wasn't properly checking for assignability of Pageable parameters to detect them but was expecting Pageable itself being used under all circumstances. This has now been opened up by an assignability check.
We now reject reactive repository metadata by RepositoryConfigurationExtensionSupport.useRepositoryConfiguration(…) assuming that Spring Data modules provide only imperative repository support by default. Reactive store modules are required to override useRepositoryConfiguration(…) anyway to not accidentally implement imperative repositories with a reactive Repository extension.
We now attempt to use private MethodHandles lookup as the first mechanism to resolve a MethodHandle for default interface methods and fall back to reflection-based Lookup construction if private lookup is not available. Reflective availability is checked lazily to prevent illegal access on enum constant construction. This approach prevents an illegal access which was logged by attempting a reflection-based lookup first.
We also introduced a FALLBACK mechanism to split encapsulated access from a fallback mechanism.
Original pull request: #307.
We now use Spring's ReflectUtils.defineClass(…) to load generated EntityInstantiators which uses internally either MethodHandles.Lookup.defineClass(…) (on Java 9 and higher) or reflective defineClass invocation on the originating ClassLoader. Class injection into the originating ClassLoader assigns the ClassLoader of the entity to the generated class which allows optimized instantiation of package-protected classes and constructors.
Original pull request: #308.
We now use a presized HashMap and Weak references in BasicPersistentEntity to improve memory and CPU profile and and avoid unmodifiable collection creation in BasicPersistentEntity.iterator(). Refactored ClassTypeInformation.from(…) lambda to method reference and predefined collection size for the cache. Reduced object instantiations during TypeDiscoverer.equals(…) by checking for type variable map emptiness to avoid Map iterator creation in Map.equals(…).
Original pull request: #305.
Added debug logging in RepositoryFactorySupport and RepositoryConfigurationDelegate so that the scanning and the instantiation of repositories can be a lot easier identified in the logs.
Use weak references in annotation and property annotation cache to retain references until the last GC root is cleared. Remove trailing whitespaces. Reformat.
Original pull request: #304.
We now use HashMap to store persistent properties of a PersistentEntity. An entity is built in a single thread so no concurrent modification happens. Concurrent reads may happen during entity usage which is fine as the PersistentEntity is not changed anymore. Previously, we used ConcurrentReferenceHashMap defaulting to soft references. Soft references can be cleared at the discretion of the GC in response to memory demand. So a default ConcurrentReferenceHashMap is memory-sensitive and acts like a cache with memory-based eviction rules.
Persistent properties are not subject to be cached but elements of a PersistentEntity and cannot be recovered once cleared.
Original pull request: #304.
We now eagerly look up the aggregate root type of a repository in the MappingContext. Some implementations might not have pre-populated the context with all entities and we need to make sure it knows about the aggregate root as other clients (e.g. the auditing subsystem) might only defensively access the entities via PersistentEntities which is not adding new entities to avoid store clashes.
ProxyProjectionFactory and ResultProcessor require a DefaultConversionService to convert values for projection proxies and to post-process query method results. Creating instances of these types requires an instance of the conversion service which previously created a DefaultConversionService instance (along all converter registrations) upon ProxyProjection/ResultProcessor instantiation.
We now use the shared instance that is initialized once and shared across all ProxyProjection/ResultProcessor instances to reduce garbage and improve the CPU profile.
We now calculate the number of expected default masks to filter synthetic constructors that do not match the expected parameter count. A Kotlin constructor with argument defaulting generates a synthetic integer argument for every 32 constructor arguments. This is independent of the number of actual optional arguments.
Previously, we used an non-exact check to consider constructors as default ones if they had at least two additional arguments. This caused the wrong constructor being used if the non-synthetic types matched the types of the default constructor.
Removed the explicit registration for JodaTime and ThreeTenBP to JSR-310 converters (originally introduced to support the unifying lookup of the last modified date in the auditing subsystem) as reading converters. This avoids the warning reporting that the source types (JodaTime and ThreeTenBP LocalDateTime) not being store-native types (which usually indicates a superfluous converter registration).
Updated the test cases to make sure these warnings aren't trigger due to test setups causing the same issue.
Moved test cases into PropertyPathUnit test so that they're closer to the implementation. Switched to Introspector.decapitalize(…) to follow the Java Beans Specification regarding the handling of all-uppercase properties.
Original pull request: #289.
Mark Paluch
Yuki Yoshida
Oliver Gierke
Michael J. Simons
Mariusz Mączkowski
Jens Schauder
Alex Bondarev