Why Lombok’s Getter/Setter Naming Breaks MyBatis Inserts and How to Fix It

Problem with Lombok‑generated Getter/Setter Methods

In a project we used Lombok’s @Data annotation to generate boilerplate code such as getters, setters, and toString. When inserting an entity with MyBatis, all fields were persisted correctly except the nMetaType enum field, which was always stored as NULL.

Root Cause

Lombok generates getter and setter method names based on the field name. For a field whose first letter is lowercase and the second letter is uppercase (e.g., nMetaType), Lombok creates getNMetaType and setNMetaType. MyBatis, however, follows the JavaBeans convention and expects getnMetaType / setnMetaType (the second character should be lowercase). Because the method names do not match MyBatis’s expectations, the framework cannot find the property and writes NULL to the database.

MyBatis PropertyNamer Logic (Simplified)

public static final String methodToProperty(String name) {
    if (name.startsWith("is")) {
        name = name.substring(2);
    } else if (name.startsWith("get") || name.startsWith("set")) {
        name = name.substring(3);
    } else {
        throw new ReflectionException("Error parsing property name '" + name + "'.  Didn't start with 'is', 'get' or 'set'.");
    }
    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;
}

The crucial part is the second if block: if the second character of the stripped name is uppercase, the method returns the name unchanged, which is why getNMetaType becomes the property name NMetaType instead of nMetaType.

Demonstration Test

@Test
public void foundPropertyNamer() {
    String isName = "isName";
    String getName = "getName";
    String getnMetaType = "getnMetaType";
    String getNMetaType = "getNMetaType";
    Stream.of(isName, getName, getnMetaType, getNMetaType)
        .forEach(methodName -> System.out.println(
            "Method name: " + methodName + " Property name: " + PropertyNamer.methodToProperty(methodName)));
}

Output:

Method name: isName Property name: name
Method name: getName Property name: name
Method name: getnMetaType Property name: nMetaType
Method name: getNMetaType Property name: NMetaType

Solutions for Lombok Issue

Rename the field so that the first two letters are lowercase (e.g., nmetaType), or explicitly define the getter/setter with the expected naming.

If the database schema and existing APIs cannot be changed, generate the getter/setter manually in the IDE to match MyBatis’s expectations.

Problem with @Accessor(chain = true) in EasyExcel

When exporting data with EasyExcel, newly added DTO classes that use the Lombok @Accessor(chain = true) annotation stopped working. The underlying cause is that EasyExcel relies on CGLIB’s BeanMap, which in turn uses Java’s Introspector to discover getter and setter methods.

Why It Fails

CGLIB calls Introspector to locate methods that start with get, set, or is. The Introspector only treats a method as a setter if its return type is void. The Lombok‑generated chainable setters return the object itself, so they are ignored, causing EasyExcel to miss those properties.

Relevant Code Snippets

// In com.alibaba.excel.read.listener.ModelBuildEventListener
BeanMap.create(resultModel).putAll(map);

// In java.beans.Introspector (simplified)
if (method.getReturnType() == void.class && name.startsWith(SET_PREFIX)) {
    // simple setter handling
}

Solutions for @Accessor Issue

Remove the @Accessor(chain = true) annotation so that Lombok generates standard void setters.

Wait for a new EasyExcel version that uses a reflection library capable of handling non‑void returning setters, or replace the underlying CGLIB usage with a custom mapper.

Both problems illustrate how code‑generation tools can clash with framework conventions, and the fixes involve either aligning naming conventions or adjusting the generated method signatures.