Why Lombok’s Getter/Setter Naming Breaks MyBatis and EasyExcel (and How to Fix It)

Setter‑Getter Method Pitfall

In a Java project we used Lombok’s @Data annotation to generate getters, setters and toString methods, but when inserting an entity with MyBatis the nMetaType enum field was always persisted as NULL despite the object containing a value.

Problem discovery

Debugging the MyBatis insert showed that the nMetaType property was correctly set in the Java object, yet the generated SQL used a NULL value for the corresponding column.

Root cause

Lombok generates getter and setter names based on the exact field name. For a field whose first two letters are nM (lower‑case then upper‑case), Lombok creates getNMetaType and setNMetaType. MyBatis (and the JavaBeans specification used by IDEs) expects the methods to be getnMetaType and setnMetaType (the second letter should be lower‑case). Because the method names do not match the expected pattern, MyBatis cannot map the property and writes NULL.

@Data
public class NMetaVerify {
    private NMetaType nMetaType;
    private Long id;
    // ... other fields
}

public void lombokFound() {
    NMetaVerify nMetaVerify = new NMetaVerify();
    nMetaVerify.setNMetaType(NMetaType.TWO); // note the capital N
    nMetaVerify.getNMetaType();
}

The standard JavaBeans implementation (used by MyBatis, IDEA and the JDK) generates the following methods for the same field:

public NMetaType getnMetaType() { return nMetaType; }
public void setnMetaType(NMetaType nMetaType) { this.nMetaType = nMetaType; }

MyBatis 3.4.6 parses method names with the PropertyNamer class. When the second character of the property name is uppercase, the parser returns the original name (e.g., getNMetaType → NMetaType), which does not match the field name nMetaType and therefore the mapping fails.

Solution

Rename the field so that the first two letters are both lowercase (e.g., nMetaType → nmMetaType) or use a naming convention that avoids the upper‑case second character.

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

@Accessor(chain = true) Annotation Issue

Problem discovery

When exporting data with EasyExcel, previously working entity classes suddenly failed after adding the Lombok @Accessor(chain = true) annotation to enable fluent setters. The exported Excel file missed the newly added fields.

Root cause

EasyExcel relies on Alibaba’s cglib library, which in turn uses the JDK Introspector to discover bean properties. The introspector expects a setter method to have a void return type and a name that starts with set. The Lombok @Accessor(chain = true) annotation changes the generated setter to return the object itself (for chaining), breaking the Introspector detection and causing the fields to be ignored during export.

public class UserDto {
    @Accessor(chain = true)
    private String userName;
    // Lombok generates: public UserDto setUserName(String userName) { ... }
}

The underlying cglib.BeanMap.create(...).putAll(map) call only processes standard JavaBean setters, so the fluent setters are skipped.

Solution

Remove the @Accessor(chain = true) annotation from entities that need to be exported with EasyExcel.

Alternatively, wait for a new EasyExcel version that replaces cglib with a library that supports non‑void fluent setters, or contribute a fix to the project.