[Discussion & Question] Confusion about the use case where clazz != headClass in ClassUtils#declaredExcelContentProperty

[bengbengbalabalabeng]

Parameter Description:

• clazz：actual data type
• headClass：configuration data type

In the ClassUtils#declaredExcelContentProperty method, there exists logic that allows the headClass and clazz to be inconsistent, and the ExcelContentProperty object defined by clazz will override the one from headClass.

To understand the applicable scenarios of this design, I tried the following two patterns that trigger clazz != headClass, but found that neither produced the expected results in actual execution.

1. Parent/Child Class Pattern

Model Definition:

@Data
public class ExcelSuperModel {
    @ExcelProperty(value = "Super NAME")
    private String name;
}

@EqualsAndHashCode(callSuper = true)
@Data
public class ExcelModel extends ExcelSuperModel {
    // Mode 1: Expected to override the parent class's field header name with the same name
    @ExcelProperty(value = "Sub NAME")
    // Mode 2: Expected to override the default behavior of parent class fields with the same name, set to ignore
    // @ExcelIgnore
    private String name;
}

Run Test

// Now headClass = ExcelSuperModel.class, clazz = ExcelModel.class
FesodSheet.write(output, ExcelSuperModel.class)
          .sheet()
          // datas() ruturn List<ExcelModel>
          .doWrite(datas());

Result: The @ExcelProperty or @ExcelIgnore setting in the subclass is invalid, and the header in the Excel file remains "Super NAME".

The logic of headNameList and ignore has already been processed when the ExcelHeadProperty#initColumnProperties method calls ClassUtils#declaredFields. Here, only ExcelSuperModel ( = headClass) is always processed, without considering the annotations of ExcelModel ( = clazz) at all.

Note: In the ClassUtils#doDeclaredFieldContentMap method, the implementation for retrieving all fields also has an overriding issue when handling fields with the same name in parent and child classes. For details, refer to the fix in PR 427.

2. Interface/Implementation Class Pattern

Model Definition:

public interface ExcelSuperInterface {
    void setName(String name);
    String getName();
}

@Data
public class ExcelModel implements ExcelSuperInterface {
    @ExcelProperty(value = "Impl NAME")
    private String name;
    
    @ExcelProperty(value = "ADDRESS")
    private String address;
}

Run Test

// Now headClass = ExcelSuperInterface.class, clazz = ExcelModel.class
FesodSheet.write(output, ExcelSuperInterface.class)
          .sheet()
          // datas() return List<ExcelModel>
          .doWrite(datas());

Result: @ExcelProperty setting is completely ineffective, and the exported Excel does not contain headers at all.

Question

Both of the above will trigger the logic of clazz != headClass, but the results do not meet expectations.

Therefore, what I want to explore is:

1. If the current architecture requires that the headClass must be strictly consistent with the clazz, is the merge/overwrite logic in ClassUtils#doGetExcelContentProperty for clazz != headClass redundant?
2. Are there any specific business scenarios I haven't covered that are specifically designed to leverage this clazz != headClass logic?