AI导读：在一个使用 Lombok 的项目中，遇到了属性命名和工具映射的问题。通过 Lombok 的 @Data 注解自动生成 Getter 和 Setter 方法时，部分属性（如 oTime、mMs、mMl）无法正确映射，原因在于 Lombok 的命名规则与工具（如 MapStruct）之间的兼容性问题。具体来说，Lombok生成的方法命名符合 JavaBeans 规范，但某些工具错误解析了大小写差异，导致映射失败。为了解决该问题，提供了几种方案，包括手动定义 Getter/Setter 方法、调整 Lombok 的生成规则、修改属性命名或配置映射工具。最终选择手动定义 Getter/Setter 方法作为解决方案。通过此问题，作者反思了规范命名和工具兼容性的重要性，建议在开发中灵活调整解决方案。

前提

在最近的一个项目中，我遇到了一次令人头疼却颇具学习价值的问题。这篇文章记录了这个问题的背景、原因分析以及最终的解决方案，希望对大家有所帮助。

问题背景

在项目中，我使用了 Lombok 来简化代码。在一个实体类中定义了一些属性，比如 dataId, epiLat, oTime, mMs 和 mMl 等。通过 @Data 注解，我让 Lombok 自动为这些属性生成 Getter 和 Setter。然而，当我尝试用 MapStruct 或其他工具对这些属性进行映射时，出现了以下错误提示：

1	No property named "oTime" exists in source parameter(s). Did you mean "OTime"?

奇怪的是，dataId 和 epiLat 这些属性都能正常映射，只有 oTime, mMs, mMl 报错。这让我百思不得其解，毕竟它们的定义方式是一样的。

问题原因分析

通过查阅资料和调试，我发现问题出在属性命名规范和 Lombok 的行为上。这里分两点来说：

JavaBeans 规范与 Lombok 的 Getter/Setter 生成规则
根据 JavaBeans 规范：
- 如果属性名的第一个字母小写，而后面紧跟一个大写字母，比如 oTime，Lombok 会将它识别为驼峰命名，并生成 getOTime() 和 setOTime() 方法。
- 对于类似 mMs 的属性，Lombok 会生成 getMMs() 和 setMMs()。
  这些方法名理论上是符合规范的，但某些工具（如 MapStruct）会错误地解析为 getoTime() 和 setoTime()，导致工具无法正确找到这些方法。
属性大小写的差异导致工具误解析
部分工具（包括 MapStruct 和一些框架）对属性名的解析可能不够智能，尤其是以小写字母开头但紧接着有大写字母的属性。它们会认为 oTime 的 Getter 方法应该是 getoTime()，而不是 Lombok 实际生成的 getOTime()。

解决过程

为了解决这个问题，我尝试了多种方法，最终找到了一些有效的方案。

方案 1：手动定义 Getter/Setter

最直接的办法就是手动为问题属性定义 Getter 和 Setter 方法，明确指定方法名。例如：

public class MyClass {
    private String oTime;

    public String getoTime() {
        return oTime;
    }

    public void setoTime(String oTime) {
        this.oTime = oTime;
    }
}

这样可以完全绕过 Lombok 的自动生成逻辑，避免工具和 Lombok 之间的命名解析差异。

方案 2：调整 Lombok 的生成行为

如果希望继续使用 Lombok，可以通过 @Getter 和 @Setter 注解为特定字段指定方法名。例如：

public class MyClass {
    @Getter(name = "getoTime")
    @Setter(name = "setoTime")
    private String oTime;
}

这样，Lombok 会按指定名称生成方法，满足工具对方法名的要求。

方案 3：调整属性命名

另一个简单直接的解决办法是调整字段名，使其符合更常见的 Java 命名规范。例如：

将 oTime 改为 otime。
将 mMs 改为 mms 或 mmS。
这样，Lombok 会生成更符合工具预期的 Getter/Setter 方法。

方案 4：调整映射工具的配置

对于使用 MapStruct 的场景，可以通过 @Mapping 注解手动指定映射规则。例如：

@Mapper
public interface EarthquakeConvert {
    @Mapping(source = "OTime", target = "oTime")
    TargetClass toTarget(SourceClass source);
}

如果是全局的映射需求，也可以调整 MapStruct 的全局配置，让它不区分大小写：

1	mapstruct.defaultPropertyNameStrategy=CASE_INSENSITIVE

最终解决方案

在我的场景中，我选择了方案 1 ——手动定义 Getter 和 Setter 方法。尽管这一方法略显繁琐，但它可以直接解决问题，且不会影响项目的其他部分。对于类似问题，我也建议大家根据实际需求选择适合的方案。

总结与反思

通过这次问题的排查，我深刻认识到 JavaBeans 规范和工具之间的微妙差异，以及 Lombok 在某些特殊场景下的局限性。这些经验对我有几个启发：

规范命名的重要性：尽量遵循常见的 Java 命名习惯，可以避免很多工具之间的兼容性问题。
工具行为要了解透彻：Lombok 和 MapStruct 的行为虽然强大，但在使用前最好详细了解它们的实现机制。
灵活选择解决方案：面对问题时，不必拘泥于一种方式，根据项目需求和团队习惯灵活调整。

hl128k Blog

记录一次Lombok属性命名问题的排查与解决

前提