BouncyCastle版本冲突，供应商不合作

Question

由于与 BouncyCastle 的版本冲突，我目前陷入了集成 Java 包的困境。

我们内部开发了一个组件，使用当地税务局提供和维护的官方 Java API 来处理发送到我们当地税务局（不是“国税局”，而是另一个欧洲国家的同等税务机构）的数据文件。我们平台的另一个模块使用来自证书颁发机构的组件来执行经过认证的文件时间戳。两者都必须集成到部署在客户站点的单个 Web 应用程序中。

您可能知道，这两个包所依赖的 BouncyCastle 包已经经历了多次公共 API 更改，因此后续版本不再具有二进制兼容性。

税务局提供“cryptotools.jar”包，该包依赖于以下内容：

<dependency org="org.bouncycastle" name="bcprov-jdk15on" rev="1.49"/>
<dependency org="org.bouncycastle" name="bcpkix-jdk15on" rev="1.49"/>

证书颁发机构提供“jades-kernel”时间戳包，该包取决于

<dependency org="org.bouncycastle" name="bcmail-jdk15"     rev="1.45"/>
<dependency org="org.bouncycastle" name="bcprov-jdk15"     rev="1.45"/>
<dependency org="org.bouncycastle" name="bcprov-ext-jdk15" rev="1.45"/>
<dependency org="org.bouncycastle" name="bctsp-jdk15"      rev="1.45"/>

将这两个包放在类路径上会导致所有 BouncyCastle 包都转储到我的WEB-INF/lib文件夹中，这通常听起来不错

但是，如果我尝试启动包含所有这些包的 Web 应用程序，我会得到这样的说法Error：类扩展了最终方法。我不会发布堆栈跟踪，这与我的问题无关

如果我删除 BC 的两个版本（1.45 或 1.49）中的任何一个，其中一个模块将无法编译。好吧，它们都已经编译好了，所以它们不会简单地链接到它们引用的类/方法。

我已经向 CA（我们与 CA 签有 Java API 维护合同）报告了这种情况，使用的是较旧的 BC 版本（该版本存在 Black Duck 发现的安全漏洞，因此我的客户让我很痛苦）。CA 尚未合作。他们需要发布与更新版本的 BouncyCastle 兼容的新版本的加密 API。

我和我的老板（C 级老板）正在将问题升级到 CA 层级，根据我们当地的幽默，很快我们就会升级到Francis

说到幽默，请允许我用视觉的方式分享一下我现在的感受

提问时间，现在回到严肃的讨论

假设我们的供应商不合作，或者至少没有及时遵守我们的监管期限。税务局不会明显地将其 Java API 降级到旧的 BC 版本。

我们怎样才能摆脱这个依赖地狱呢？例如，我知道 log4j 有一个“bridge”包，可以缓解那些尚未升级的包在 1.x 和 2.x 版本之间发生的破坏性 API 更改。当两个模块依赖于不同的BC版本时，我们如何使它们共存？

我将发布一个可能的解决方法，但这不是我们的首选解决方案。

Answer 1

本质上，Java 不是为此而构建的，Maven 当然也不是（因为有一个基本假设，即在解决此类冲突时，任何较新的版本都是旧版本的完美替代品）。

据我了解，您有一个整体应用程序，因此由于您无法在物理上拆分类路径，因此您可以从逻辑上进行拆分。

处理此问题的一种方法是在多个类加载器中运行应用程序，以便 jar 文件永远不会“接触”。我之前问过“如何在多个类加载器中运行”问题 -想要并行运行非线程安全库 - 可以使用多个类加载器来完成吗？- 这种方法与加载不在类路径上的 jar 相结合可能是可行的。