java - BouncyCaSTLe 版本冲突，厂商不合作

Question

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

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

您可能知道，这两个包所依赖的 BouncyCaSTLe 包已经经历了几次公共(public) API 更改，因此后续版本不再与二进制兼容。

Revenue Service 提供“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 应用程序，我会收到一个错误，指出类扩展了 final 方法。我不会发布堆栈跟踪，这与我的问题无关

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

我已将这种情况报告给 CA(我们与 CA 签订了 Java API 的维护契约(Contract))，使用的是较旧的 BC 版本(它具有 Black Duck 发现的安全漏洞，因此我的客户让我的生活痛苦不堪) . CA 尚未合作。他们需要发布与最新版本的 BouncyCaSTLe 兼容的新版本的加密 API。

我和我的老板(C 级老板)正在将问题升级到 CA 层次结构，并且根据我们本地的幽默，很快我们将升级到 Francis

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

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

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

我们如何摆脱这种依赖 hell ？例如，我知道 log4j 有一个“桥接”包来缓解 1.x 和 2.x 版本之间的 API 中断变化尚未升级的软件包。两个依赖不同BC版本的模块如何共存？

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

Answer 1

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

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

处理此问题的一种方法是在多个类加载器中运行您的应用程序，以便 jar 文件永远不会“接触”。我之前问过一个“如何在多个类加载器中运行”的问题 - Want to run non-threadsafe library in parallel - can it be done using multiple classloaders? - 这种方法结合加载一个 不 在类路径上的 jar 可能是可行的。