Gradle测试Bouncy Castle签名冲突致ExceptionInInitializerError排查求助

一、彻底排查类路径中的Bouncy Castle依赖 #

• 打印完整测试运行类路径，直接定位所有BC相关jar：
  执行Gradle命令：./gradlew :your-module:printTestRuntimeClasspath（替换your-module为实际模块名），在输出中搜索包含bouncycastle、bc-fips、bcpkix-fips的条目，检查是否有未预期的版本或来源。
• 生成完整依赖树，排查间接依赖：
  执行./gradlew dependencies --configuration testRuntimeClasspath，遍历整个依赖树，确认是否有其他模块或第三方依赖偷偷引入了不同版本的Bouncy Castle包——这是dependencyInsight容易漏掉的场景。
• 检查本地手动添加的jar：
  确认测试目录（如src/test/resources、lib）下有没有手动放置的BC相关jar，这类文件不会被Gradle依赖树扫描到。
• 验证依赖排除规则：
  如果之前配置过依赖排除，检查排除规则是否覆盖了所有可能引入冲突BC版本的依赖，比如：

  implementation('some-dependency') {
      exclude group: 'org.bouncycastle', module: 'bc-fips'
  }
  

二、验证包签名信息差异 #

• 定位报错类的加载来源：
  在测试任务的JVM参数中添加-verbose:class，运行测试后，在日志中搜索org.bouncycastle.util.test.TestRandomBigInteger，找到它的加载路径（类似[Loaded org.bouncycastle.util.test.TestRandomBigInteger from jar:file:/xxx/bc-xxx.jar!/]），确定该类所在的jar。
• 用jarsigner验证jar签名：
  对找到的jar和同包其他类所在的jar，执行签名验证命令：
  jarsigner -verify -verbose -certs /path/to/target-bc.jar
  对比不同jar的签名者信息、证书链，确认是否存在签名不匹配的情况。
• 检查jar的MANIFEST.MF文件：
  解压目标jar，查看META-INF/MANIFEST.MF中的签名相关字段（如Signature-Version、Created-By等），对比不同jar的字段是否一致。

三、额外解决建议 #

• 强制统一BC版本：
  在根项目的build.gradle中添加版本强制规则，确保所有依赖使用指定版本的BC包：

  configurations.all {
      resolutionStrategy {
          force 'org.bouncycastle:bc-fips:1.0.1'
          force 'org.bouncycastle:bcpkix-fips:1.0.3'
      }
  }
  

• 清理Gradle缓存：
  执行./gradlew clean build --no-build-cache，清除可能残留的旧版本jar缓存。
• 检查测试任务的自定义类路径：
  确认测试任务配置中有没有通过classpath、from等方式额外引入的jar，比如：

  test {
      classpath files('libs/some-jar.jar')
  }
  

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