[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?

[nkuprins]

While checking this, I hit something that does look wrong:

@Data 
class Super {
    @ExcelProperty("Super NAME") 
    @DateTimeFormat("yyyy") 
    Date name;
}

@EqualsAndHashCode(callSuper = true) 
@Data 
class Sub extends Super {
    @ExcelProperty("Sub NAME")
    @DateTimeFormat("yyyy-MM-dd") 
    Date name;  // shadows
    
    @ExcelProperty("CONTROL")    
    @DateTimeFormat("yyyy-MM-dd") 
    Date control; // nothing shadows this
}

FesodSheet.write(file, Sub.class).sheet().doWrite(listOfSub);

Expected

Sub NAME	CONTROL
2020-03-04	2020-03-04

Actual

Sub NAME	CONTROL
2020	2020-03-04

The cause seems to be in doDeclaredFieldContentMap: it walks from subclass to superclass but put unconditionally, so the superclass lands last and wins. This may be a fix then:

if (!fieldContentMap.containsKey(field.getName())) {
    fieldContentMap.put(field.getName(), excelContentProperty);
}

[bengbengbalabalabeng]

No offense, I just want to confirm whether the issue you identified is the root cause of this discussion, or an additional problem discovered along the way.

[nkuprins]

No offense, I just want to confirm whether the issue you identified is the root cause of this discussion, or an additional problem discovered along the way.

I am fine with deleting a comment and creating an issue for that if you want :)
I did not consider it off-topic because I based my examples on your examples and also looked at the clazz and headClass

[bengbengbalabalabeng]

Thanks! Just to clarify, I didn’t mean your example was off-topic.

I'm raising this for confirmation because your example shares similarities with the earlier PR #427. The root cause of that PR was in the field collection logic, which had no direct connection to clazz != headClass. This can be fixed in the following ways (doDeclaredFieldContentMap()):

fesod/fesod-sheet/src/main/java/org/apache/fesod/sheet/util/ClassUtils.java

Lines 308 to 321 in 5274b2f

	List<Field> tempFieldList = new ArrayList<>();
	Map<String, Field> fieldNameToField = new HashMap<>();
	Class<?> tempClass = clazz;
	// Prefer subclass fields, only process the bottom-most (subclass) definition for fields with the same name
	while (tempClass != null) {
	for (Field field : tempClass.getDeclaredFields()) {
	String fieldName = FieldUtils.resolveCglibFieldName(field);
	if (!fieldNameToField.containsKey(fieldName)) {
	fieldNameToField.put(fieldName, field);
	tempFieldList.add(field);
	}
	}
	tempClass = tempClass.getSuperclass();
	}