Preface

MapStruct is a code generator that greatly simplifies the implementation of mappings between Java Bean types based on a conventionally preferred approach to configuration. The generated mapping code uses simple method calls, so it is fast, type-safe and easy to understand. mapStruct’s expression function is designed to deal with the mapping of special object properties, such as the DTO status property into PO status requires further processing, this time you need to use the expression function. Here is not to repeat the use of MapStruct issues, more tutorials can refer to the document.

Problems encountered

First look at a mapping code: @Mapper(imports)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

@Mapper(imports = CustomProcessors.class)
public interface DepartmentsMapper {

    @Mapping(target = "status", expression = "java( DepartmentsMapper.toStatus(department.getStatus()) )")
    DepartmentsVO boToVo(DepartmentBO department);

    static String toStatus(String status){
        return status + "XXX";
    }
}

The original semantics of this code is that when assigning the status property of DepartmentBO to DepartmentsVO, some simple conversion is needed, and the method of conversion is the static method toStatus defined in the Mapper interface. The final MapStruct generated code also handles the assignment of other properties. The generated code is as follows.

javabean

You can see that except for the specified status property, which is added to the code in the expression, all the other properties are also added, which is not the effect we want.

Find the reason

The owner repeatedly checked the official documentation, and finally came close to pulling down the source code to look at the implementation logic, and finally had a flash of a guess as to the possible reason. The above code on the use of expressions is not a problem, the official documentation is also written very clearly. The main reason is that a hidden feature of MapStruct is triggered here: a closer look at the generated code reveals that only the fields of the Integer attribute are added to the code in the expression, and the owner deduces that as long as the conversion method is defined in the interface defining the maping, it will be automatically applied to the conversion of attributes of the same type. This was verified later, for example, when I removed the definition of the expression.

1
2
3
4
5
6
7
8
9

@Mapper(imports = CustomProcessors.class)
public interface DepartmentsMapper {

    DepartmentsVO boToVo(DepartmentBO department);

    static Integer toStatus(Integer status){
        return status + 1;
    }
}

The final generated code still has all the values of the Integer property plus the toStatus processing.

Conclusion

This last feature found in the official documentation can not find the slightest description, in fact, can be considered a very good feature, you can unify the processing of the same type of property, such as when the property is an object, just in the blogger’s scenario can not be used. The final solution is to move the code definition in the expression out of the Mapper interface just fine.