Before this commit we haven't properly resolved methods on a root object provided by an EvaluationContextExtension that was using varargs. With a vararg method, the number of parameters handed into the method is not necessary equal to the number of parameters. We previously simply skipped methods with a different number of arguments. We now try direct matches first but calculate valid varargs alternatives in case that initial lookup fails and try to match those alternatives.
This lookup is implemented in ….util.ParameterTypes now and used by ….spel.spi.Function. The latter now also handles the actual invocation of those methods properly by collecting the trailing arguments into an array.
Various fast returns and the use of Class instead of TypeDescriptor led to e.g. List<BigDecimal> not getting properly converted to List<Integer> leading to unexpected ClassCastExceptions when the collection elements where accessed.
We now consider more than 16 immutable and nullable Kotlin properties per bucket in generated PropertyAccessors.
Previously only the first 16 properties were considered due to truncation of the defaulting bitmap. We used SIPUSH to render the defaulting mask in bytecode which is intended for 16 bit integers (short). Migrating to LDC (runtime constants) preserves the actual constant value of 32 bits and so we're considering now full buckets.
We now skip PersistentPropertyPath instances pointing to auditing properties for which the path contains a collection or map path segment as the PersistentPropertyAccessor currently cannot handle those. A more extensive fix for that will be put in place for Moore but requires more extensive API changes which we don't want to ship in a Lovelace maintenance release.
Related tickets: DATACMNS-1461.
We now catch the MappingException produced by trying to set auditing property paths containing null intermediate segments and ignore those. A less expensive (non-Exception-based) approach is going to be introduced for Moore as it requires API changes to the property path setting APIs.
Related tickets: DATACMNS-1438.
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.