Java 11升级至17后Hibernate 6.3.0.CR1出现运行时错误

看起来你遇到的是Hibernate 6.3.0.CR1在Java 17环境下处理查询参数时的类型解析问题，这个错误提示declaredParameterType为null，导致无法调用resolveExpressible方法。结合Java版本升级的背景，我来分享几个可能的排查方向和解决办法：

• 显式指定查询参数类型
  有些情况下，Java 17的类型擦除或反射行为变化会导致Hibernate无法自动推断参数类型。如果你的代码里是直接传值给setParameter，不妨试试带明确类型的重载方法，比如：

  // 原来的写法可能是这样
  query.setParameter("userId", userId);
  // 改成显式指定类型
  query.setParameter("userId", userId, Long.class);
  

  这样能帮Hibernate明确参数的绑定类型，避免declaredParameterType为null的问题。

• 调整Java 17的模块/反射权限
  Java 17对模块系统（JPMS）和反射访问的限制比Java 11更严格：

  • 如果你的项目是模块化的（有module-info.java），要确保实体类所在的包对Hibernate开放反射访问，比如在module-info.java里添加：

    opens com.yourproject.entities to org.hibernate.core;
    exports com.yourproject.entities;
    

  • 如果是非模块化项目，可能需要添加JVM启动参数放宽反射限制，比如：

    --add-opens java.base/java.lang=ALL-UNNAMED
    --add-opens java.base/java.util=ALL-UNNAMED
    

    具体参数可以根据Hibernate实际需要访问的包来调整。

• 升级或更换Hibernate版本
  你用的6.3.0.CR1是候选发布版本，可能存在针对Java 17的兼容性bug。建议优先尝试升级到Hibernate 6.3的正式稳定版（如果已经发布），或者降级到经过更多验证的6.2.x系列版本，正式版通常会修复这类跨Java版本的兼容性问题。

• 检查查询与实体的类型匹配
  确认你的JPQL/HQL查询中，参数的类型和对应实体属性的类型完全匹配。比如不要把Integer类型的参数传给实体里的Long类型属性，这种细微的类型不匹配在Java 11可能被Hibernate兼容处理，但在Java 17的严格类型检查下，可能导致Hibernate无法正确解析参数类型。

备注：内容来源于stack exchange，提问作者Matt