Java 记录值得拥有为其量身打造的映射器

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家

自 Java 16 起，Java 记录（Records）已处于稳定状态，随着 Java 21 成为长期支持（LTS）基线，它们正无处不在地出现——数据传输对象（DTOs）、值对象、领域模型。它们天生不可变、简洁且语义清晰。

但这里存在一个无人提及的缺口：Java 生态系统中的每个对象映射器都是在记录（Records）出现之前构建的。它们是围绕 JavaBean 设计的——即具有 getter、setter 和无参构造函数的可变对象。而记录不具备这些特性。那么会发生什么？这些库作为事后补救措施，勉强添加了部分记录支持，因此破绽百出。

我构建了 Immuto 来填补这一缺口。

retrofitting（后期适配）记录支持的问题

记录的身份由其规范构造函数定义：

public record PersonDTO(Long id, String fullName, String email) {}

该构造函数是创建 PersonDTO 的唯一方式。没有 setter。除非你自己编写，否则没有构建器。组件访问器是只读的。

现有的映射器并非为此设计。为了与记录配合使用，它们要么：

生成不存在的 setter 调用（并在运行时失败）
要求你编写一个可变构建器作为变通方案
回退到对私有字段的反射——完全绕过规范构造函数

这些都是运行时故障。在运行代码之前，你无法得知存在问题。

Immuto 的不同之处

Immuto 是一个注解处理器——它在执行 mvn compile 期间运行，工作方式与 Lombok 和基于注解处理工具（APT）的方法相同。它生成普通的 .java 源文件，直接调用你记录的规范构造函数。无反射。无 setter。无运行时意外。

@RecordMapper
public interface PersonMapper {

    @Mapping(target = "fullName",
             expression = "java(source.firstName() + \" \" + source.lastName())")
    PersonDTO toDto(PersonEntity source);

    @InheritInverseConfiguration(name = "toDto")
    PersonEntity toEntity(PersonDTO source);
}

在执行 mvn compile 后，Immuto 将 PersonMapperImpl.java 写入 target/generated-sources 目录。它看起来完全像你手动编写的代码：

@Generated免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。