Why Lombok’s Getter/Setter Naming Breaks MyBatis and EasyExcel

In a recent project, the author encountered a puzzling issue where a field annotated with Lombok's @Data was not persisted correctly by MyBatis. The entity class NMetaVerify contains a field private NMetaType nMetaType;. While other fields were inserted successfully, nMetaType remained null in the database.

Debugging revealed that the Lombok‑generated getter and setter for this field are getNMetaType() and setNMetaType(NMetaType nMetaType), where the first character after the prefix is capitalized. MyBatis, however, follows the JavaBeans convention and expects getnMetaType() and setnMetaType(NMetaType nMetaType) (lower‑case second character). Because the method names differ, MyBatis fails to map the property, leaving the column null.

MyBatis Property Name Parsing

The MyBatis class org.apache.ibatis.reflection.property.PropertyNamer extracts property names from getter/setter signatures. It trims the "get", "set" or "is" prefix and then applies the following rule:

if (name.length() == 1 || (name.length() > 1 && !Character.isUpperCase(name.charAt(1)))) {
    name = name.substring(0, 1).toLowerCase(Locale.ENGLISH) + name.substring(1);
}
return name;

This logic lower‑cases the first character only when the second character is not uppercase. For getNMetaType, the second character is uppercase, so the method returns the original name "NMetaType", which does not match the field name "nMetaType".

EasyExcel @Accessor Issue

When using EasyExcel to export data, the same naming problem appears if the entity class is annotated with @Accessor(chain = true). EasyExcel relies on cglib’s BeanMap, which in turn uses Java’s Introspector to discover property descriptors. The introspector also follows the JavaBeans convention and therefore cannot locate the Lombok‑generated methods for fields whose second character is uppercase.

Solutions

Rename fields so that the first two characters are lowercase (e.g., private NMetaType nMetaType → private NMetaType nmetaType), ensuring Lombok generates standard JavaBean getters/setters.

If the database schema and existing APIs cannot be changed, manually generate the correct getter/setter methods (e.g., using IDE code generation) and remove Lombok for those specific fields.

For the EasyExcel issue, remove the @Accessor(chain = true) annotation, or wait for a library update that supports non‑void returning setters or alternative reflection mechanisms.

These adjustments align Lombok‑generated code with MyBatis and EasyExcel expectations, preventing null values and reflection failures.