JMeter5.3下JSR223预处理器添加int型JSON属性时Ubuntu环境报包装类转换错误

问题根因 #

• 报错和操作系统本身无直接关联，本质是两个环境类加载到的Gson库版本不一致，配合setStrictJava(true)开启的严格类型校验逻辑触发了不兼容问题。
• 代码中开启的setStrictJava(true)会强化Groovy的类型匹配严格度，关闭Groovy对自动装箱、重载方法匹配的容错逻辑：
  • Mac环境下无论GUI/CLI运行无报错，说明该环境类加载优先级正确，实际加载的是JMeter 5.3官方二进制包内置的Gson 2.8.6版本，该版本在strict模式下对原生int类型的方法重载匹配逻辑兼容
  • Ubuntu环境报错，基本是因为没有使用官方JMeter二进制包部署，或者JVM类加载顺序异常，最终加载到了存在兼容缺陷的旧版Gson（多为2.8.5及更早版本），这类旧版本在strictJava模式下，对addProperty系列方法的原生int入参匹配存在bug，会错误触发包装类转换异常
• 将int入参改为字符串就能正常运行，本质是绕开了Gson对数值类型入参的方法匹配缺陷，并没有解决版本不一致的核心问题。

快速排查验证 #

• 在Ubuntu环境的JSR223脚本最开头增加一行日志，打印实际加载的Gson版本：log.info("加载的Gson版本号: {}", com.google.gson.Gson.class.getPackage().getImplementationVersion())，将输出结果和Mac环境的同位置输出做对比，即可直接确认版本不一致问题
• 排查Ubuntu环境的Jar包加载路径：
  • 检查JMeter安装目录下lib文件夹内的Gson jar包版本，确认是否和Mac环境的gson-2.8.6.jar文件大小、版本完全一致
  • 排查CLASSPATH环境变量、JVM扩展类路径、用户目录下的自定义JMeter lib文件夹，是否存在其他版本的Gson jar包被JVM优先加载

对应解决措施 #

• 临时兼容修复（短期可用）：
  • 所有传入addProperty方法的原生数值类型，显式转换为包装类再传入，匹配正确的方法重载，比如将metaData.addProperty("frequency", 100)改为metaData.addProperty("frequency", Integer.valueOf(100))，绕开旧版Gson的方法匹配bug
• 根本问题修复：
  • 统一两个环境的JMeter依赖版本，优先从Apache官方获取同版本的二进制压缩包部署到Ubuntu环境，不要使用系统apt源、第三方仓库安装的JMeter包，这类包附带的依赖库版本常和官方版本存在差异
  • 清理所有非JMeter官方路径下的Gson jar包，确保JVM只加载JMeter内置目录下的Gson版本，避免类加载优先级混乱
  • 若必须使用自定义版本的Gson，可在JSR223脚本中通过JMeter的类加载器手动加载指定路径的Gson类，隔离系统路径的类加载干扰

注意事项 #

• 开启setStrictJava(true)后，Groovy的动态类型容错能力会被大幅关闭，不要依赖自动装箱逻辑去匹配第三方库的重载方法，跨环境运行的脚本尽量对方法入参做显式类型声明，减少版本兼容问题
• 同版本号的JMeter不代表依赖库完全一致，手动拷贝脚本到其他环境时，不要默认所有依赖的第三方Jar包行为完全相同，涉及类型严格校验的逻辑必须做跨环境的版本一致性校验

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