In Kotlin, it is idiomatic to deal with return value that could have or not a result with nullable types since they are natively supported by the language. This commit adds CrudRepository.findByIdOrNull(…) variant to CrudRepository#findById that returns T? instead of Optional<T>.
Original pull request: #299.
Extended IterableToStreamableConverter in use in QueryExecutionConverters so that it can not only return Streamable instances but also instances of types that have a factory method or constructor taking a Streamable (by making use of the ObjectToObjectConverter in a default ConversionService).
We now fall back to reflection-based PropertyAccessor/EntityInstantiator strategies when framework types are not visible by the entity's ClassLoader.
Typically, we use class generation to create and load PropertyAccessor and EntityInstantiator classes to bypass reflection. Generated types are injected into the ClassLoader that has loaded the actual entity. Generated classes implement framework types such as ObjectInstantiator and these interfaces must be visible to the ClassLoader that hosts the generated class. Some arrangements, such as OSGi isolate class repositories so the OSGi class loader cannot load our own types which prevents loading the generated class.
Original pull request: #324.
We now inspect all methods that match the wither method pattern (name, accepting a single argument) to find the most specific method returning the actual entity type.
Previously, we attempted to find a method only considering name and argument properties and not the return type. This lookup strategy could find a method returning the entity super type that isn't assignable to the entity type.
Original pull request: #323.
We now use ConcurrentHashMap as type instead of HashMap to properly synchronize concurrent updates to missing cache elements.
The previously used HashMap was not thread-safe so concurrent modifications resulted in ConcurrentModificationException.
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.
