When beanmapper tries to map a field from the source's superclass to a field of the target with the same fieldname a strict mapping exception is thrown. When strict mapping is turned off, the field is not mapped; the target field remains null.

Test code (UserRole is an enum and RoleResult is a class with public 'name' field):

    @Test
    public void beanMapper_shouldMapFieldsFromSuperclass() {
        BeanMapper beanMapper = new BeanMapperBuilder().build();
        RoleResult result = beanMapper.map(UserRole.ADMIN, RoleResult.class);
        Assert.assertEquals(UserRole.ADMIN.name(), result.name);
    }

Results in a BeanStrictMappingRequirementsException.

    @Test
    public void beanMapper_shouldMapFieldsFromSuperclass() {
        BeanMapper beanMapper = new BeanMapperBuilder().setApplyStrictMappingConvention(false).build();
        RoleResult result = beanMapper.map(UserRole.ADMIN, RoleResult.class);
        Assert.assertEquals(UserRole.ADMIN.name(), result.name);
    }

Results in an assertion failure.

Bumps jackson-databind from 2.13.4 to 2.13.4.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Optionals are a common usage pattern in JPA Entities to indicate the possibility of a field being null and so replacing null checks with a niceish api.

Currently if an Entity has an java.util.Optional getter which needs to be mapped to a non optional Result field BeanMapper:

• in strict mode fails with Missing matching properties for source [java.util.Optional] > target [EntityResult]
• in non-strict mode fails by not mapping any fields to the entity.

The following example demonstrates the problem: (note the mandatory package prefix)

package nl.optionalexample;

public class OptionalMappingExample {

    public static class MyEntity {
        private String value = "42";
        private MyEntity child;
        public String getValue() {
            return value;
        }
        public Optional<MyEntity> getChild() {
            return Optional.ofNullable(child);
        }
    }
    
    public static class MyEntityResult {
        public String value;
        public MyEntityResult child;
    }
    
    public static void main(String[] args) {
        BeanMapper mapper = new BeanMapperBuilder()
                .addPackagePrefix("nl")
                .setApplyStrictMappingConvention(true)
                .build();
        mapper.map(new MyEntity(), MyEntityResult.class);
    }
}

The error thrown:

11:46:54.418 [main] DEBUG io.beanmapper.strategy.MapToClassStrategy -     {
11:46:54.422 [main] ERROR io.beanmapper.core.BeanStrictMappingRequirementsException - Missing matching properties for source [java.util.Optional] > target [nl.videma.repartitie.rightsholder.OptionalMappingExample.MyEntityResult]* for fields:
11:46:54.423 [main] ERROR io.beanmapper.core.BeanStrictMappingRequirementsException - > MyEntityResult.child
11:46:54.423 [main] ERROR io.beanmapper.core.BeanStrictMappingRequirementsException - > MyEntityResult.value
Exception in thread "main" io.beanmapper.core.BeanStrictMappingRequirementsException
	at io.beanmapper.core.BeanMatch.validateBeanMatchValidity(BeanMatch.java:75)
	at io.beanmapper.core.BeanMatch.validateMappingRequirements(BeanMatch.java:68)

#114 Beanfield class determined by how it will be accessed

Currently, the field property always determines the class of a BeanProperty. This leads to confusing and faulty behaviour when the method accessors differentiate from the field, leading, for example, to the wrong BeanConverters being chosen or the wrong casts being made. The behaviour should be legitimate, since the developer may choose to map within a class. BeanMapper must make use of the access knowledge to determine the class of the BeanProperty.

A BeanProperty will have a notion of how it will be accessed for its role (either source or target). The possibilities are: field, getter, setter or no access. The access type will have an influence on the reported class of the beanfield.

When a BeanProperty is created, it will immediately build up its understanding of the way its property will be accessed and the class it must return upon being queried.

The creation process for BeanProperty instances has been abstracted into its own class. The set of static methods was hard to test and convoluted with its relatively large number of parameters that is being passed around.

Structural use of BeanField has been renamed to BeanProperty; a bean field is one of the two ways a property may be accessed, the other is through its method accessor (get/set). The property is the combination of its field and method accessors.

A collection list will no longer be offered for clear/reuse when the class type of the accessor method differs from the class type of the field.

An error sometimes occurred in the BeanMapper when it attempted to invoke a getter method in the PropertyDescriptorPropertyAccessor.

The short version of the solution:

The setAccessible method should be called very soon prior to calling
the invoke method rather than only once at the creation of the
PropertyDescriptorPropertyAccessor.

For the long version of the solution, let me take you down the rabbit hole:

The error occurred in the following piece of code, when the 'invoke'
method was called:

@Override
public Object getValue(Object instance) {
    if (!isReadable()) {
        throw new BeanGetFieldException(instance.getClass(), getName());
    }

    try {
        return descriptor.getReadMethod().invoke(instance);
    } catch (IllegalAccessException e) {
        throw new BeanGetFieldException(instance.getClass(), getName(), e);
    } catch (InvocationTargetException e) {
        throw new BeanGetFieldException(instance.getClass(), getName(), e);
    }
}

This read method was made accessible in the constructor of the
PropertyDescriptorPropertyAccessor:

public PropertyDescriptorPropertyAccessor(PropertyDescriptor descriptor) {
    this.descriptor = descriptor;
    makeAccessable(descriptor.getReadMethod());
    makeAccessable(descriptor.getWriteMethod());
}

private void makeAccessable(Method method) {
    if (method != null) {
        method.setAccessible(true);
    }
}

And the PropertyDescriptorPropertyAccessor is only created once for each
method and afterwards the same instance is used to retrieve the value
from the appropriate method. This can be verified by checking its memory
address.

When the getReadMethod() is called on the descriptor, the same instance
is returned from the memory. Or so it seems.

When you step into the getReadMethod() you can see that it retrieves the
read method from a reference:

Method readMethod = this.readMethodRef.get();

When we step into the get() method on the readMethodRef field,
we see the following body:

 Method get() {
    if (this.methodRef == null) {
        return null;
    }
    Method method = this.methodRef.get();
    if (method == null) {
        method = find(this.typeRef.get(), this.signature);
        if (method == null) {
            this.signature = null;
            this.methodRef = null;
            this.typeRef = null;
        }
        else {
            this.methodRef = new SoftReference<>(method);
        }
    }
    return isPackageAccessible(method.getDeclaringClass()) ? method : null;
}

A SoftReference is created if the current value of methodRef is null,
the next time the same SoftReference instance is returned. On this
SoftReference's referent object (which is an instance of Method)
a setAccessible(true) call is done when the PropertyDescriptorPropertyAccessor
is created.

In the JavaDoc of a SoftReference, the following comment is shown:

 * Soft reference objects, which are cleared at the discretion of the garbage
 * collector in response to memory demand.  Soft references are most often used
 * to implement memory-sensitive caches.

It seems that at some point in time the reference is deleted when the garbage
collector decides it is time. Then, a new reference is created for which the
setAccessible method has NOT been called. This results in an
IllegalAccessException and halts the mapping.

When we call setAccessible just before we call the invoke, we set the accessibility
on the SoftReference we just got back or created. The garbage collector can not clean
this up in the meantime as we still have a reference to it.

The same fix was performed for both field and and method accessors.

Issue #83 In the resolution of issue #78 the definition of getter fields has been tightened, because previously all private fields were tagged as available as well. One project made use of this loophole by reading the name field of an enumeration class to a String field. With the new fix this is no longer possible, since the name field is private.

This fix makes an exception for the name field of an enum class. It will be considered available for reading.

Stacktrace:

apr 05, 2016 7:45:36 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [dispatcher] in context with path [/api] threw exception [Request processing failed; nested exception is java.lang.ArrayIndexOutOfBoundsException: 0] with root cause
java.lang.ArrayIndexOutOfBoundsException: 0
    at io.beanmapper.core.unproxy.DefaultBeanUnproxy.unproxy(DefaultBeanUnproxy.java:21)
    at io.beanmapper.core.unproxy.SkippingBeanUnproxy.unproxy(SkippingBeanUnproxy.java:36)
    at io.beanmapper.BeanMapper.getBeanMatch(BeanMapper.java:176)
    at io.beanmapper.BeanMapper.matchSourceToTarget(BeanMapper.java:166)
    at io.beanmapper.BeanMapper.map(BeanMapper.java:149)
    at io.beanmapper.BeanMapper.map(BeanMapper.java:114)
    at io.beanmapper.BeanMapper.map(BeanMapper.java:90)
    at nl.mad.voliere.buizerd.model.website.WebsiteService.checkNow(WebsiteService.java:269)
    at nl.mad.voliere.buizerd.model.website.WebsiteService$$FastClassBySpringCGLIB$$11439aa7.invoke(<generated>)

code of DefaultBeanUnproxy:

public class DefaultBeanUnproxy implements BeanUnproxy {
    public DefaultBeanUnproxy() {
    }
    public Class<?> unproxy(Class<?> beanClass) {
        String name = beanClass.getName();
==>     return name.contains("$")?beanClass.getInterfaces()[0]:beanClass;
    }
}

name is: nl.mad.voliere.buizerd.checker.WebsiteCheckerExecutor$UrlTestResult UrlTestResult is an inner class of WebsiteCheckerExecutor. There are no interfaces.

Records use a different style of getter-methods, specifically, they use the exact name of the parameter passed to the record's definition. While it is possible to map records to classes if you write your own beanmapper-compliant getters, that defeats at least some of the purpose of records.

By using the following the record and tests, we receive different exceptions based on the strictness set in the BeanMapper.

public record PersonRecord(String name, String place) {

}

@Test
void mapPersonRecordToPersonResultStrict() {
    beanMapper = new BeanMapperBuilder().setApplyStrictMappingConvention(true).build();
    PersonRecord personRecord = new PersonRecord("Henk", "Zoetermeer");
    PersonResult personResult = beanMapper.map(personRecord, PersonResult.class);
    assertEquals(personRecord.name(), personResult.name);
    assertEquals(personRecord.place(), personResult.place);
}

@Test
void mapPersonRecordToPersonResultNotStrict() {
    beanMapper = new BeanMapperBuilder().setApplyStrictMappingConvention(false).build();
    PersonRecord personRecord = new PersonRecord("Henk", "Zoetermeer");
    PersonResult personResult = beanMapper.map(personRecord, PersonResult.class);
    assertEquals(personRecord.name(), personResult.name);
    assertEquals(personRecord.place(), personResult.place);
}

As stated earlier, these tests will pass if you write getters for them like so:

public record PersonRecord(String name, String place) {

    public String getName() {
        return this.name;
    }

    public String getPlace() {
        return this.place;
    }

}

Records are somewhat likely to become commonplace, so this would be a worthwhile addition to BeanMapper.

When using @MergedForm with the patch option it throws an error because of the new java 17 Reflection rules. This doesn't seem to be "form dependant" as I've been able to successfully reproduce the error on any @MergedForm when I've added the patch=true option to it.

FormDefinitionResult update(@Valid @MergedForm(value = FormDefinitionForm.class, patch = true, mergeId = "id") FormDefinition formDefinition) {

error: Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @5a4aa2f2

I've also tried to manually patch it according to the beanmapper.io docs, however this also throws the same error. As far as I can tell it has something to do with the downsizeSource(...), as it looks like the @MergedForm patch also uses that function.

Bumps jackson-databind from 2.11.3 to 2.12.6.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

@BeanProperty could only be used with a name property. Adding a value alias allows this annotation to be used without any prefix and just the name of the property.

Also corrected all warnings about javadoc (missing returns).

Fixes #122

Various classes exist that function - or should function - solely as a data-carrier.

An example of such a class is the BeanPair-class:

public class BeanPair {

    private final Class<?> sourceClass;
    private final Class<?> targetClass;
    private boolean sourceStrict = false;
    private boolean targetStrict = false;

    public BeanPair(Class sourceClass, Class targetClass) {
        this.sourceClass = sourceClass;
        this.targetClass = targetClass;
    }

    public BeanPair withStrictSource() {
        this.sourceStrict = true;
        return this;
    }

    public BeanPair withStrictTarget() {
        this.targetStrict = true;
        return this;
    }

    public boolean isSourceStrict() {
        return sourceStrict;
    }

    public boolean isTargetStrict() {
        return targetStrict;
    }

    public Class getSourceClass() {
        return sourceClass;
    }

    public Class getTargetClass() {
        return targetClass;
    }

    public boolean matches(Class<?> currentSourceClass, Class<?> currentTargetClass) {
        return
                currentSourceClass.isAssignableFrom(sourceClass) &&
                        currentTargetClass.isAssignableFrom(targetClass);
    }

}

A more elegant solution could look something like the following:

public record BeanPair<S, T>(Class<S> sourceClass, Class<T> targetClass) {

    private static final String INSTANTIATION_FAILURE_MESSAGE = "Could not instantiate BeanPair. %s is null.";

    public BeanPair {
        Objects.requireNonNull(sourceClass, () -> INSTANTIATION_FAILURE_MESSAGE.formatted("Source-class"));
        Objects.requireNonNull(targetClass, () -> INSTANTIATION_FAILURE_MESSAGE.formatted("Target-class"));
    }

    public <U, V> boolean matches(Class<U> currentSourceClass, Class<V> currentTargetClass) {
        return
                currentSourceClass.isAssignableFrom(sourceClass) &&
                        currentTargetClass.isAssignableFrom(targetClass);
    }
}

Using this approach would cut down on boilerplate, introduce serialization-safety through the validation in the record-class' constructor, and adhere to the single-purpose principle. This would, however, require a different actor to hold the information regarding the strictness of the source and target. A good candidate for this responsibility would be the StrictMappingProperties-class. Incidentally, that class is also a candidate for refactoring to a record.

Complex classes are often provided with a static factory method, used to instantiate an object of the complex class. Furthermore, it would be beneficial for the use of Singletons to support such methods.

A fairly simple method of supporting static factory methods could be achieved through a new annotation BeanFactoryMethod.

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface BeanFactoryMethod {
    String[] value();
}

This annotation would accept a String-array, containing the names of the fields that would need to be provided to the method as arguments, in the correct order.

In order to process the BeanFactoryMethod, a new implementation of the BeanInitializer-interface could be provided, to properly invoke the factory method.

It is important to note that, as this process runs before a target-object has been initialized, there is no object of the target type available for use in reflection. As such, the factory method MUST be static, as the call to it will use Method#invoke(Object, Object...). As no object of the target type is available, we would be forced to pass null as the first parameter. This is only possible for static methods.

Whenever a source-object contains a null-value for a field that must be mapped to a record, the RecordToAnyConverter#copyFieldsToIntermediary(Object, Map)-method will throw a NPE. This is due to an unsafe call to Object#getClass().

The solution would be to check for a null value in the RecordToAnyConverter#copyFieldsToIntermediary(Object, Map)-method. Tests should also be added for this situation.

I came up with a different proposal than the ticket suggests because I was a little bit confused with DefaultValueProvider accepting 2 different Types. Like, which type will the DefaultValue have? I could not make sense out of it, if I get the issue correctly.

Although it's a bit too many classes with the suggested way, it is both extendable for new Types as well as for new Providers. As an example I added a secondary provider and called it Maximum.

The DefaultValues-class is rather rigid, and extensions of the class are inherently invasive.

I propose to replace the DefaultValues-class with a Provider-interface, and an implementation DefaultValuesProvider. Please find the example implementation below.

@FunctionalInterface
public interface Provider<S, T> {

    T get(S source);

}

An implementation for the Provider-interface, that would offer roughly the same functionality as the DefaultValues-class, could look like this:

public class DefaultValueProvider<S, T extends S> implements Provider<Class<S>, T> {

    private static final Map<Class<?>, ?> DEFAULT_VALUES = Map.ofEntries(
            Map.entry(boolean.class, false),
            Map.entry(byte.class, (byte) 0),
            Map.entry(short.class, (short) 0),
            Map.entry(int.class, 0),
            Map.entry(long.class, 0L),
            Map.entry(float.class, 0.0F),
            Map.entry(double.class, 0.0),
            Map.entry(List.class, Collections.emptyList()),
            Map.entry(Set.class, Collections.emptySet()),
            Map.entry(Map.class, Collections.emptyMap()),
            Map.entry(Optional.class, Optional.empty())
    );

    @Override
    public T get(Class<S> source) {
        if (source == null)
            return null;
        return (T) DEFAULT_VALUES.get(source);
    }
}

It could also be implemented as a record:

public record DefaultValuesProviderRecord<S, T extends S>(Map<Object, Object> defaultValues) implements Provider<S, T> {

    private static final Map<Object, Object> DEFAULT_VALUES = Map.ofEntries(
            Map.entry(boolean.class, false),
            Map.entry(byte.class, (byte) 0),
            Map.entry(short.class, (short) 0),
            Map.entry(int.class, 0),
            Map.entry(long.class, 0L),
            Map.entry(float.class, 0.0F),
            Map.entry(double.class, 0.0),
            Map.entry(List.class, Collections.emptyList()),
            Map.entry(Set.class, Collections.emptySet()),
            Map.entry(Map.class, Collections.emptyMap()),
            Map.entry(Optional.class, Optional.empty())
    );

    public DefaultValuesProviderRecord() {
        this(DEFAULT_VALUES);
    }

    @Override
    public Map<Object, Object> defaultValues() {
        return Collections.unmodifiableMap(this.defaultValues);
    }

    @Override
    public T get(S source) {
        return (T) this.defaultValues().get(source);
    }
}

Aside from the benefits for extensibility of the Provider itself, this will also positively impact testing, and the composition of Form - and Result-classes.

I also propose to allow, not one, but any number of providers for any given mapping, by modifying the Configuration to include a Collection of Provider-objects. This would allow users a greater degree of control over the mapping of their objects, and would be especially easy to use, due to the Provider-interface being a functional interface.