We now provide the context class for private MethodHandle lookup in the context of the actual entity class to properly use MethodHandles.defineClass(…) and to avoid illegal access warnings caused by reflective access to the defineClass(…) method on class loaders.
Also, we now use the internal type name without adding the reference type decorator when casting the result of a wither invocation. CHECKCAST allowed on earlier Java runtimes (version 8 and earlier) to use the reference decorator (L…;) around the type name. Java 9 and newer reject this format with a ClassFormatError.
Original pull request: #318.
We now apply best-effort caching instead of atomic caching for custom conversions and type mapping. This change is a workaround for a Java 8 bug in ConcurrentHashMap where the computeIfAbsent(…) operation unconditionally locks nodes even when the node is already present.
The workaround is to assume the optimistic case by looking up the key and then falling back to computeIfAbsent if the key is absent.
Before:
TypicalEntityReaderBenchmark.simpleEntityReflectivePropertyAccessWithCustomConversionRegistry thrpt 10 6487423,969 ± 349449,326 ops/s
DefaultTypeMapperBenchmark.readTyped thrpt 10 38213392,961 ± 5080789,480 ops/s
DefaultTypeMapperBenchmark.readUntyped thrpt 10 47565238,929 ± 855200,560 ops/s
After:
TypicalEntityReaderBenchmark.simpleEntityReflectivePropertyAccessWithCustomConversionRegistry thrpt 10 7361251,834 ± 278530,209 ops/s
DefaultTypeMapperBenchmark.readTyped thrpt 10 122523380,422 ± 3839365,439 ops/s
DefaultTypeMapperBenchmark.readUntyped thrpt 10 181767673,793 ± 3549021,260 ops/s
Original pull request: #319.
We now correctly calculate the number of defaulting masks used to represent constructor arguments. Previously, we've been one off which caused that Kotlin classes with 32/33 parameters weren't able to be instantiated.
We also now reuse KotlinDefaultMask to apply defaulting calculation and removed code duplicates.
We now no longer consider bridge modifiers when looking up Kotlin default methods. We previously included checks whether a synthetic default method is also a bridge method to take all specifics of synthetic methods into account. With Kotlin 1.3, the compiler no longer sets the bridge flag. This behavior change would previously prevent usage of the copy method with classes compiled with Kotlin 1.3.
Default method discovery is still guesswork and Kotlin compiler reverse engineering as there is no documentation on how to look up this kind of methods.
Further references:
* https://youtrack.jetbrains.net/issue/KT-24415 - Remove bridge flag from default methods.
* https://youtrack.jetbrains.net/issue/KT-27317 - No documented rules for discoverability of generated methods.
We now use the primary constructor of Kotlin classes to discover the copy method. We use the primary constructor args to compare signatures and only use the copy method that takes all parameters in the constructor args order. This allows to find the appropriate copy method in case the class declares multiple copy methods.
We now also cache the copy method (KCallable) to reduce lookups in BeanWrapper.
Original pull request: #312.
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.
Previously, ConvertingPropertyAccessor did not override PersistentPropertyAccessor.setProperty(PersistentPropertyPath, Object), so that the target value had to be of the leaf property's type. We now implement that method and convert it into that type before invoking the super method.
Core information about the bootstrap mode, timing and number of repositories created is now logged in info. Individual repository registration is logged in trace now.
Related tickets: DATACMNS-1368.
Both the XML and annotation based configuration sources now support a bootstrap mode configuration property that allow to configure whether repositories are eagerly initialized unless declared as lazy, initialized in a deferred way (just before the application context finishs bootstrapping) or entirely lazy (upon first usage, i.e. a method invocation).
We now register a custom AutowireCandidateResolver that will consider all injection points of lazy repositories lazy too. This will prevent them to accidentally trigger downstream infrastructure initialization.
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.
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.
CustomRepositoryImplementationDetector now works in two differend modes. If initialized with an ImplementationDetectionConfiguration, it will trigger a canonical, cached component scan for implementation types matching the configured name pattern. Individual custom implementation lookups will then select from this initially scanned set of bean definitions to pick the matching implementation class and potentially resolve ambiguities.
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.
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.
The newly introduced method indicates whether any properties have to be populated to create instances of the entity. This is useful for objects that are completely initialized through their constructors as converters then can avoid iterating over all properties just to find out none of them have to be populated.
Mark Paluch
heowc
Oliver Gierke
Vjkumar Bokar
Tobias Hermann
Yuki Yoshida
Michael J. Simons