If multiple repositories pointing to a single domain type are found we now favor the one registered as primary bean definition. This allows allows reliable disambiguation on which repository is supposed to be used for generic repository interactions.
Related tickets: DATAREST-923.
Added Streamable.toStreamable() and ….toStreamable(Collector) to allow the creation of a Streamable from streams wither using a default List-based intermediate collector (former) or providing an explicit one (latter).
We now use StringUtils.hasLength(…) in the check whether to drop request elements from binding instead of ….hasText(…) as the latter drops blank strings so that's impossible to search for properties that contain a blank.
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.
Oliver Drotbohm
Francisco Soler
Christoph Strobl
Mark Paluch
Sebastien Deleuze
heowc
Vjkumar Bokar