Hibernate3迁移至Hibernate5.6.1：Formatter类相关代码适配问题

核心差异说明 #

Hibernate3版本的Formatter接口（含类型格式化、SQL格式化两类场景）原本定义了多个待实现方法，Hibernate5.6.1版本对该接口做了函数式改造，调整为仅包含1个抽象方法的函数式接口，部分场景下还新增了泛型约束。

适配修改步骤 #

• 第一步先确认你使用的Formatter所属包路径，两种常见场景对应包路径如下：
  • 业务类型值格式化场景：org.hibernate.type.format.Formatter（泛型接口）
  • SQL语句格式化场景：org.hibernate.engine.jdbc.spi.Formatter（非泛型，入参为SQL字符串）
• 第二步调整实现类的接口声明
  如果是类型格式化场景，需要指定泛型参数为你需要格式化的目标类型，示例：

  // Hibernate3旧写法
  public class CustomDateFormatter implements Formatter {
  // Hibernate5.6新写法
  public class CustomDateFormatter implements Formatter<Date> {
  

• 第三步统一实现单方法签名
  删掉原来接口要求的其他多余方法，仅保留接口约定的单个format方法即可，原有业务逻辑可以直接复用：
  类型格式化场景示例：

  // 仅保留该方法即可，其他旧方法直接删除
  @Override
  public String format(Date value) {
    if (value == null) {
      return "";
    }
    return new SimpleDateFormat("yyyy-MM-dd").format(value);
  }
  

  SQL格式化场景示例：

  @Override
  public String format(String sql) {
    // 原有SQL格式化逻辑直接复用即可
    return sql;
  }
  

• 第四步调整Formatter注册逻辑
  如果你原本通过Hibernate配置注册自定义Formatter，Hibernate5.6版本可以通过MetadataBuilder或者SessionFactoryBuilder的对应方法注册新实现类的实例即可，注册逻辑不需要大幅修改。

注意事项 #

• Hibernate3版本中Formatter接口要求的其他过时方法直接删除即可，不会影响正常功能
• 泛型场景下不需要再做多余的类型强转，直接使用泛型参数对应的类型处理即可，可降低类型转换异常风险

内容的提问来源于stack exchange，提问作者andy